Cloudhouse Guardian (Guardian) is a platform designed to track and manage configuration across your estate's infrastructure, both in the cloud or on-premises. Guardian simplifies security and compliance by offering cross-functional features that work together to create a robust cybersecurity solution. For example, an enterprise that performs manual tracking and management of configurations can use Guardian to automate and streamline workflows that are error-prone and time-consuming, ensuring more reliable and continuous monitoring and compliance with security policies.
This guide covers all the essentials needed to get started in Guardian: read on to understand the key terminology you'll encounter while using Guardian, a step-by-step process of how to set up your Guardian instance, as well as advice on how to implement more advanced functionality.
-Page-1.drawio.png)
Terminology
As you embark on your Guardian journey, there are some key terms that you ought to familiarize yourself with. Doing so will make communicating with Support staff and using the Guardian documentation a lot easier. The following table lists some of the most commonly used terms and their meanings.
Tip: For a more detailed break down of key concepts in Guardian, see Guardian Concepts.
| Term | Description |
|---|---|
| Guardian Instance |
The software that is required to run the Guardian platform. Depending on what deployment method you choose, on-premises or Cloudhouse-hosted, the subsequent set up requirements will vary. For more information, see Guardian Instance. |
| Virtual Guardian Appliance |
The on-premises version of a Guardian instance. The appliance works as a black-box, where only Guardian employees will have access to modify its contents. For more information, see Virtual Guardian Appliance. |
| Agent |
The Agent software is a service provided by Guardian for scanning nodes. In contrast to Agentless scanning, which uses a remotely deployed Connection Manager that can scan multiple nodes, the Agent service is installed directly on the node intended to be scanned. For more information, see Guardian Agent. |
| Connection Manager |
The Connection Manager is a piece of software that performs Agentless node scans, allowing for fine-grained network access control. Using a Connection Manager means that Guardian doesn't need direct access to your entire network. In contrast to the Guardian Agent, one Connection Manager can be used to scan multiple nodes (remotely) at a time. For more information, see Connection Managers. |
| Node | A node represents any scannable object in your environment. This can be a system, service, application, or device that is scanned in Guardian. For more information, see Nodes. |
| Node Group | The basic organizational unit for nodes in Guardian. Node groups are used for customizing scan options and can also be used for reporting. A node can be a member of an unlimited number of node groups. For more information, see Node Groups. |
| Environment |
The top-level organizational unit for nodes, allowing you to organize nodes into groups that match your own infrastructure, such as development, staging, and production environments. For more information, see Environments. |
| Scan | A snapshot of a node’s configuration state at a point in time. When a node is scanned, the results are presented in a visual and interactive display, with a list of all configuration items divided into sections. For more information, see Node Scan Results. |
| Sections | In a node's scan results, all configuration items are grouped into sections. These sections are built-in and cannot be modified, and they vary between node types. Examples of common sections include Users, EnvVars, and ServiceKeys. |
| Configuration Item | A piece of configuration data, displayed in a node's scan results. For example, this could be a file, a registry setting, a software package version, or more. For more information, see Node Scan Results. |
| Attribute |
Each configuration item has any number of attributes. For example, a file configuration item may have attributes for:
Attribute checks can be defined within a policy, see Attribute Checks. |
Now that you're familiar with Guardian’s key terminology, we'll walk you through the steps required to set up your Guardian instance. Understanding these terms will help you navigate the setup process more effectively, as each concept plays a key role in configuring Guardian.
Step 1 – Choose Hosting Option
Before you can start using Guardian, the first step is to decide how to host your Guardian instance. Depending on the option you choose, the deployment, configuration, and operation of your instance will vary.
Based on your needs and preferences, you can choose one of the following hosting options:
-
Cloudhouse-Hosted – For Cloudhouse-hosted instances, you are receiving the Guardian SaaS. Cloudhouse creates, deploys, and hosts your Guardian instance in our cloud-hosted location (no set up is required). There are no additional infrastructure costs, you receive automatic upgrades, as well as ease of maintenance, support, and troubleshooting as the Guardian team can access the instance directly. However, this method requires Internet access (all scanning services require an Internet connection to function).
Tip: This is the preferred hosting method as Cloudhouse can monitor and maintain your Guardian instance directly, providing tailored support.
-
On-Premises – For on-premises deployments, you are required to provision resources for your own Virtual Guardian Appliance. Once you're ready, Guardian Support will collaborate with you to install and configure the application. Then, you are required to host and maintain your appliance. For this method, you maintain control over your data, storing it behind your own firewall, with no Internet access required. Likewise, you can generally deal with more nodes using the virtual Guardian appliance. However, you are responsible for your own infrastructure costs.
Note: Additionally, due to the nature of an on-premises appliance, the support model varies. It is harder for Cloudhouse to maintain visibility of health status, manual upgrades are required, and support calls must be conducted over a screen share with remote control of the computer required to access the virtual Guardian appliance.
Once you decide which hosting method to use, you can deploy your instance of Guardian and get set up.
Step 2 – Deploy Guardian Instance
Depending on what hosting option you chose, the method of deploying your Guardian instance will vary. For more information, see Guardian Instance.
Cloudhouse-Hosted
For Cloudhouse-hosted deployments, your Guardian instance will be automatically configured in our cloud-hosted location. This process can take up to one week. Once completed, you will be contacted by Guardian Support to set up an account. Then, you can immediately start designing your Guardian architecture.
On-Premises
For on-premises deployments, you need to provision the virtual appliance required to deploy your instance of Guardian, see Virtual Guardian Appliance for more information. Once you have provisioned and configured the virtual appliance, you are required to notify your Cloudhouse Representative so that they can arrange a meeting to install and configure the application. Once you have an account set up, you can begin designing your Guardian architecture.
Step 3 – Design Guardian Architecture
Next, you want to design your Guardian architecture in accordance with your infrastructure requirements. At this stage, you will have already agreed to a node license count, i.e. the number of nodes allocated by your license for scanning and monitoring in Guardian. According to the number of nodes intended to be scanned, as well as the type of nodes intended to be scanned, you can accurately forecast what scanning services (and how many) are required to maintain regular and efficient scanning of your node set.
In addition, it is important to consider where you want those scanning services to be deployed. For example, if you have three different domains in scope for regular scanning, then you would need three separate services (most likely Connection Managers) set up in order to handle those commands efficiently. There are many requirements specific to your own infrastructure that will need to be determined with your Cloudhouse Representative. Once you have a good idea of what is required, you can begin setting up your Guardian architecture.
Step 4 – Set Up Scanning Services (Agent-Based/Agentless)
One of the most important steps to ensure that your Guardian instance performs well and can accommodate the amount of scans required per node is to make an informed decision about the best and most efficient way of setting up your scanning services. With appropriate planning and discovery, at this stage, you should have a good understanding of how you need to architect your Guardian instance in order to meet your infrastructure's requirements.
For context, Guardian performs its node configuration scanning by running commands on the node to gather configuration data. Those commands can be performed by an Agent or Agentlessly via one (or both) of Guardian's scanning services: the Agent and the Connection Manager, respectively. The results of each scanning method are the same and, as such, you can choose to use any combination of Agent-based or Agentless collection methods in your environment. For best results, Cloudhouse recommend that you employ a combination of both scanning services. For more information on each method, see below and/or refer to Agent-Based or Agentless?.
Tip: For more information on the list of devices supported for monitoring in Guardian, see Supported Devices.
Agent-Based
For Agent-based scanning, the Agent must be installed on each of your target nodes. The service then scans the node it is installed on and polls the Guardian appliance over HTTPS port 443, checking if there is any work to be completed every 10 seconds. The Agent scans one node per instance. For more information, see Guardian Agent.
Tip: Agent nodes are added to the Monitored tab (Inventory > Monitored) once they've been set up. For more information, see Monitored Nodes.
Agentless
For Agentless scanning, a Connection Manager is used to connect to your target nodes remotely. Essentially working as a connection proxy, the Guardian Connection Manager provides a single point of management for all configuration, logging, and updating of nodes. Once deployed, the Guardian Connection Manager has the capacity to scan more than a hundred nodes remotely. Depending on the node type, the Connection Manager can connect via an SSH connection, a WinRM connection, or an API. The Connection Manager can also be deployed to the Guardian appliance or deployed as a satellite Connection Manager. For more information, see Connection Managers.
Tip: When setting up multiple Connection Managers, it is best practice to set up one or more Connection Manager groups in advance. When Guardian receives a request to scan an Agentless node it checks what Connection Manager group it is assigned to first. This is because Connection Managers within the same group share the load for node scans, integrations syncs, etc. Setting up Connection Manager groups can help with more efficient load balancing. For more information, see Connection Manager Groups.
Step 5 – Provision Service Accounts
Agentless Scanning Only
Service user accounts are necessary for Agentless scanning. In most, if not all cases, you will require at least one Connection Manager to Agentlessly scan your node set. Typically, the service account for the associated Connection Manager should be configured to use WinRM or SSH (depending on the Connection Manager type) in order to avoid Access Denied-related scan error messages. Additionally, sufficient permissions are required in order to completely scan the corresponding node type.
Tip: Even if you decide not to set up a Connection Manager and use the default (built-in) Linux Connection Manager instead, a service user account is still required to authorize the connection to the target source. For more information on this service, see Default Linux Connection Manager
Each service account type must meet the following corresponding requirements:
| Service Account Type | Requirements |
|---|---|
| Linux |
The following requirements must be met in order to enable a Linux service user account for the Agentless scanning of SSH node types:
|
| Windows |
The following requirements must be met in order to enable a Windows service user account for the Agentless scanning of WinRM node types:
|
| Database |
The following requirements must be met in order to enable a database service user account for the Agentless scanning of database node types:
|
Step 6 – Set Up Your Network
Once you've set up your scanning services, you need to configure the firewall rules in Guardian so that your Agents and Connection Managers can communicate with each other over the network. Otherwise, the services will be unable to successfully scan your node set.
Each scanning service must have the following firewall rules set:
| Scanning Service | Firewall Rule |
|---|---|
| All Agent and Connection Manager types | Must be able to reach the Guardian instance on port 443 in order to poll for scan jobs and return results. |
| Linux Connection Manager |
Must be able to reach target nodes (Linux servers, Unix servers, SSH-capable network devices) on port 22. Note: This is the default port. If you are using a different port, make sure that the Connection Manager can reach the port that the administrator is using to run their SSH server. |
| Windows Connection Manager |
Must be able to reach the Guardian instance on port 5985/5986. Note: If you're scanning databases, the Connection Manager must be able to reach the database nodes on whatever ports you're using to connect to with Open Data Base Connectivity (ODBC). |
Step 7 – Add and Scan Nodes
Once your Connection Managers and/or Agents have been set up correctly with the appropriate service user accounts and your firewalls are configured, you can begin to add nodes for regular scanning and monitoring.
Add Nodes
You can add nodes to your Guardian instance via a myriad of processes. The Add Nodes tab (Inventory > Add Nodes) provides one centralized location for adding nodes. For more information on this location, see Add Nodes.
There are two main ways to add nodes in Guardian:
-
Add Nodes in Bulk – Add nodes in bulk by creating a temporary connection to your target source. For example, AWS, Azure, GCP, and more. You can then specify the type of nodes you want Guardian to detect and import to your instance. Depending on how you configure this connection, the nodes can be stored in the Detected tab for later actioning or the Monitored tab for instantaneous scanning and monitoring.
Note: This method can only be performed Agentlessly via a Connection Manager.
-
Add a Single Node – Add one node at a time from the 27 categories of supported node types in Guardian. For example, AWS, Azure, Linux, and more. Each node within that category has its own connection protocol according to the parameters stipulated by the source.
Add Integrations
Additionally, you can create an integration to a target source to automatically sync and detect nodes. With this method, you only need to set up an integration once. Guardian will then automatically sync to the target source and update your node(s) according to a specified schedule. In contrast to adding a node (in bulk or singularly) where you need to manually re-import the node(s) to ensure that it is up-to-date, or schedule a node sync job. For more information on how to do this, see Integrations.
Tip: Integrations serve additional purposes outside of node detection; you can configure actions to run when a specific event occurs in Guardian. For example, you could add a Slack integration for the purpose of triggering Slack messages to be sent in the event of a failed scan. For more information, see Actions.
Scan Nodes
Guardian stores the total configuration state of every node upon the point of scanning. As such, it is imperative to set up regular node scans for effective monitoring and evaluation. The results of a scan are displayed within the Node Scan Results page, which contains a visual breakdown of each aspect of the node's configuration, including various settings curated to enable the effective configuration and customization of data. These settings make it easy to compare systems and environments and track how a single system has changed over time. With consistent node scans, you can ensure that you are effectively tracking your node set's data as well as any configurational differences that may occur over time, allowing for rich configuration differencing. There are both manual and automated methods available for configuring your node scans. For more information, see Scan Nodes.
Tip: Additionally, you can schedule a scan job for a node, node group, or environment to run according to a specified schedule. For more information, see Scan – Job Type.
Step 8 – Uncover Guardian Features
Guardian provides a set of default configuration items that are collected during a scan. If you want to go beyond the default settings, there are a myriad of features you can use to personalize your experience.
The following list describes some of the key features you can use to organize nodes, customize scans, manage jobs, generate insightful reports, and more:
-
Node Groups – Node groups are used to organize nodes with similar properties and roles into groups. A node can belong to any number of node groups. For example, you could choose to organize your nodes according to device type, operating system, application, or any other combination of defining criteria. Then, you could apply policies, scan options, or automated jobs to run for each of the nodes within that group. The main benefit of a node group is its organizational capacity. For more information, see Node Groups.
-
Environments – Environments are the top-level organizational unit in Guardian, allowing you to organize nodes into groups that match your own infrastructure, such as development, staging, and production environments. However, if you do not want to organize your nodes according to a traditional release approach, you can organize your nodes according to any other combination of defining criteria, such as the region or operating system. Environments are flexible and designed to be configured according to the organizational structure that best suits your needs. This is the top-level organizational structure in Guardian. For more information, see Environments.
-
Connection Manager Groups – Connection Manager groups are used to organize Connection Managers of the same type into groups with similar properties and roles. For example, you could group your Connection Managers according to network topologies, time zones, or any other organizational property. When setting up multiple Connection Managers, it is best practice to set up one or more Connection Manager groups in advance. When Guardian receives a request to scan an Agentless node it checks what Connection Manager group it is assigned to first. This is because Connection Managers within the same group share the load for node scans, integrations syncs, etc. Setting up Connection Manager groups can help with more efficient load balancing. For more information, see Connection Manager Groups.
-
Scan Options – Scan options allow you to customize the scans of your node groups in the Monitored tab so that you can specify particular areas of interest when that group of nodes is scanned. For example, you could specify particular files or directories that you want to be scanned. For more information, see Scan Options.
-
Job Schedule – A job is a pre-determined action that is set to run according to a specific cycle. For example, node scans are performed once each day. However, you can modify this schedule to run according to any interval you'd prefer (every hour, every three days, etc.) The Job Schedule tab (Control > Job Schedule) contains a list of all the other job types that can be scheduled to run to automate various processes within your Guardian instance. For more information, see Job Schedule.
-
Configuration Differencing – Generate a difference report for multiple nodes, node groups, or files to access the complete set of configuration data present on each target. Within the report, you can filter the results by scan date, differences, and commonalities — all of which can be critical to uncovering and understanding inconsistencies within your node set. For more information, see Configuration Differencing.
-
Reports – Generate different types of reports in Guardian using the data available in your Inventory. Reports are useful because they let you view information for many different nodes and nodes groups at once. There are also various filtering options offered on each report so you can customize the data displayed to include only the information you want to see. For more information, see Reports.
-
Policies – Policies allow you to define a desired configuration state at the node or node group level. For example, you could create a policy in the Policies tab (Control > Policies) to ensure that a set of roles and features are installed on a node, or that certain environment variables are set. The policy checks are then run each time the node is scanned, with the results indicating whether the checks passed or failed. For more information, see Policies.
Note: Similarly, benchmarks in Guardian consist of best-practice policies outlined by the Center for Internet Security (CIS) to evaluate whether a node or node group complies with CIS standards. For more information, see Benchmarks.
-
Events – The Events page (Control > Events) displays all the events that have been performed on or within your Guardian application. For example, user logins and policy failures. Here, you can monitor and track both user-triggered and time-triggered events. Additionally, you can configure specific views to filter events by category and actions to be triggered each time a specific event occurs. For more information, see Events.
Troubleshooting and Support
If you are experiencing issues with your Guardian instance, you can refer to the Job History tab. Here, you can view failed or partial jobs and can access the error report, accompanied by descriptive error messages to determine the cause of failure and remediate a solution.
Tip: If you need further assistance, don’t hesitate to reach out by contacting helpdesk@cloudhouse.com